Law of conservation of complexity
by Larry Tesler, 1984
Original formulation
Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it—the user, the application developer, or the platform developer?
Dan Saffer와의 인터뷰
Designing for interaction 1판의 인터뷰에는 있던 내용인데 2판에서는 해당 내용이 사라짐. 책 홈페이지도 없어져서 Internet archive에서 복사:1
Q: How did you come up with the Law of the Conservation of Complexity?
In the early days of our field, when I worked at Xerox PARC, the idea of UI consistency was new and controversial. Many of us realized that consistency would benefit not only users, but also developers, because standards could be encapsulated in shared software libraries. We made an economic argument: If we establish standards and encourage consistency, we can reduce time to market and code size.
In 1983-85, when I was developing the MacApp object-oriented framework at Apple, I advocated a three-layer code model. In addition to the Macintosh Toolbox—a shared software library—and the application itself, I made the case for an intermediate layer that implemented what I called a “generic application”. A generic application was a real interactive program—with windows, menus, and commands—that did nothing at all, but did it in a standard way. You could create, open, save and print documents, but the documents lacked form and were empty of content. You built your actual application by modifying the generic application in an object-oriented way.
To sell the idea to Apple management and independent software vendors, I came up with the Law of Conservation of Complexity. I postulated that every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.
Because computers back then were small, slow and expensive, programs were designed to be compact, not easy to use. The user had to deal with complexity because the programmer couldn’t. But commercial software is written once and used millions of times. If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer’s job easier.
Whose time is more important to the success of your business? For mass market software, unless you have a sustainable monopoly position, the customer’s time has to be more important to you than your own.
The idea of the object-oriented framework, developed at PARC by Trygve Reenskaug, and the idea of the generic application, which I developed with my MacApp team, made investment in ease of use more palatable to developers by making it cheaper to reduce complexity than to increase it. The further down in the software hierarchy that you push the complexity, the less work has to be done by everybody above. MacApp’s promise was, if you make life easier for our mutual customers, we’ll make development easier for you.
nomodes.com의 인용들
Lerry Tesler 본인이 운영하는 홈페이지에서 이 법칙에 대한 다양한 관점들을 소개하고 있다:2
- “In this case, the complexity of managing the translation of object references (when moving the object to/from disk), is moved out of the hands of the programmer and into the hands of the system. The complexity is not eliminated, but rather moved around so that the programmers efforts are focused on the application problem.” — “Object Databases in Action: Technology and Application” by Tim Andrews, Chapter 4 of Information Technology in Action: Trends and Perspectives, edited by Richard Y. Wang, pp. 63-82, February 1993.
- “The law of conservation of complexity serves as a balance to the Pattern Priesthood. It becomes important to select patterns which contain enough substance as to be worth the effort, but at the same time are not so complex that only the elite understand them.” — The Patterns Handbook: Techniques, Strategies, and Applications by Linda Rising, p. 350, June 28, 1998.
- “Given … that we will continue to reduce the proportion of complexity … that we expose to the user, we may expect that the difficulty and complexity of our own tasks … will only increase over time.” — blog post by Bruce Tognazzini, September, 1998.
- “The goal of the SAP CAF is to shift as much of the complexity of developing a composite application as possible away from programmers and onto the tool itself.” — SAP NetWeaver For Dummies by Dan Woods and Jeffrey Word, p. 267, May 7, 2004.
- “With the transition rig (an adaptive sail configuration), complexity has moved from the use of the product to the design and construction. In many cases, this is a desirable trade-off, especially for mature products, whether they are software interfaces, physical controls, or even web sites.” — blog post by David Bishop, January 27, 2005; retold in Trillions: Thriving in the Emerging Information Ecology by Peter Lucas, Joe Ballay and Mickey McManus, p. 149, August 29, 2012..
- “The complexity of a business process … is like energy, it cannot be created or destroyed, it can only be moved around from one place to another.” — ITworld post by Sean McGrath, May 19, 2005.
- “As The Who told us in their 1966 song ‘Substitute,’ the simple things you see are all complicated.” — Designing for Interaction: Creating Smart Applications and Clever Devices by Dan Saffer, p. 55, July 28, 2006.
- “In short, particularly in the interactions between humans and computers, there seems to be a principle of conservation of complexity—what is complex in digital representation and computation can only be simplified at the expense of what is explicitly represented.” — Fundamentals of Software Integration by Kay Hammer and Tina Timmerman, p. 112, December 11, 2007. Independent formulation of the Law. See also pp. 270-271.
- “Talking about something being simple when not actually looking at how inevitable complexity is going to be dealt with, is asking to get into the weeds.” — blog post by Bill de hOra, August 15, 2008.
- “I think if we look at some of the most successful applications in history, we’ll find Tesler’s law at work behind their success.” — blog post by Mark Mzyk, August 17, 2008.
- “Just as energy is never lost, the minimum amount of complexity an entire system must have to achieve its goals can never be reduced, it can only be moved around.” (blog post, August 25, 2008) and “It’s also a factor in the organization … If someone (or some department) does less, then someone else must do more, else the result will not occur.” (blog post, September 3, 2008) — both by Eachan Fletcher.
- “…the total amount of complexity in a software system is always constant and can be moved across layers…. Where you place it is an architectural choice.” — Microsoft® .NET: Architecting Applications for the Enterprise by Dino Esposito and Andrea Saltarello, p. 368, October 15, 2008. Independent formulation of the Law.
- “An example of this transfer of complexity can be seen in automatic route finders … the computer carries out the calculations (of the optimum route) rather than the human user.” — Cognitive Work Analysis: Coping with Complexity by Daniel P. Jenkins, Neville A. Stanton, Paul M. Salmon and Guy H. Walker, p. 8, January 1, 2009.
- “I especially like the economic parallel which hides beneath it - how we trade, value, exchange and often disregard the scarcest resource (and currency) of all: time.” — blog post by Matt Griswold, 2010.
- “Moreover, the software vendors have left all the technical complexity for the user … The only way to get to the desired level of usability is to design software that would reflect the work process of the user (workflow) and the mental model (concepts) of the user (terminology).” — eHealth - A Global Perspective by Alan R. Shark and Sylviane Toporkoff, p. 125, March 17, 2010.
- “People who design learning-at-work programmes based on slavish Cognitive Load principles probably believe they’re shouldering the responsibility for the ‘irreducible complexity’ of learning (but) they could merely be postponing the hard work of learning. You can’t think for somebody else any more than you can eat or drink for them.” — waybacked blog post by Bunchberry & Fern, March 25, 2010.
- “The secret of creating a simple user experience is to shift complexity into the right place, so that each moment feels simple.” — Simple and Usable Web, Mobile, and Interaction Design by Giles Colborne, p. 180, September 26, 2010.
- “The automobile and its computer systems become more complex every year, but this hidden complexity transforms the driver’s task, simplifying it while making it safer.” — Living with Complexity by Donald Norman, p. 224, October 29, 2010.
- “As the apparent complexity of a system is made easier, the complexity of the designers’ task must increase to fill the gap. Great news for those designers ready for the task, and for those students studying interaction design in school today.” — review of Norman’s book by Robert Blinn, February 1, 2011.
- “Start by figuring out where the core complexity lies, then decide which part of that the user might like to have, and when in the overall process.” — Microinteractions: Designing with Details by Dan Saffer, pp. 67-69, May 20, 2013.
- “It could take the engineers many extra hours to save the users just a few seconds each, but according to Tesler that’s an appropriate trade-off. I suggest that this is the same model we should use in marketing.” — blog post by John Kuefler, November 4, 2015.
- “Complexity is thus shifted from physical infrastructure to algorithms.” — How Raffaello D’Andrea summed up his robot-assisted airport baggage concept to Kyle Chayka for The New York Times Magazine, November 13, 2016, p. 58.